home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16062 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 07:25:36 -0500
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4kdl00$rv@solutions.solon.com>
  8. References: <JSA.96Feb16135027@organon.com> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <dewar.829012486@schonberg>
  9. Reply-To: seebs@solon.com
  10. NNTP-Posting-Host: solutions.solon.com
  11.  
  12. In article <dewar.829012486@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
  13. >By a "portability problem" most people mean that you take a program 
  14. >written in language X, and try to move it to machine Y from machine Z,
  15. >and it does not work any more.
  16.  
  17. Right.  No behavior of "i=++i", or of someone twiddling the internals
  18. of a stdio FILE, can be unportable, because no program doing those is
  19. written in C.  They are portability problems of the language "incorrect
  20. C", which is beyond the intended scope of comp.lang.c.  :)
  21.  
  22. Really; any time you are writing things not specified in any spec, you
  23. have left the realm of what that spec guarantees, and nothing that
  24. happens to you is a portability problem with that spec.
  25.  
  26. It may be a weakness problem with that spec; C's spec is certainly too
  27. weak in some areas.  But it's possible to implement it on nearly anything,
  28. which was the goal.
  29.  
  30. >Portability problems are most definitely caused by writing non-portable
  31. >code. In fact in the absence of errors in the compiler of environment
  32. >on machine Y or machine Z, this is the ONLY source of portability
  33. >problems.
  34.  
  35. This, we agree on, mostly...
  36.  
  37. >However, it is definitely the case that languages vary in the ease with
  38. >which people end up writing non-portable code deliberately or
  39. >accidentally.
  40.  
  41. Also very true.  I believe it is basically impossible to meaningfully
  42. write portable machine code.  (Exceptions exist; there was a program
  43. in the IOCCC which worked on a VAX *or* a PDP.)
  44.  
  45. >For example, in C, we can't declare an integer variable without 
  46. >introducing a potential portability dpeendence on the range. Careful
  47. >writing can get around this, or certainly minimize it, but it's often
  48. >the source of porability problems. Typical Ada prograns do not suffer
  49. >from this particular problem, because even a novice Ada programmer
  50. >knows to avoid the use of predefined types in code that is intended
  51. >to be portable.
  52.  
  53. This is a known limitation of C, and may be addressed by C9X.  I hope
  54. it is; it's one of the few areas where I feel the language is fundementally
  55. incapable of doing what I want it to do.
  56.  
  57. Luckily, it doesn't affect most of what I'm working on these days.
  58.  
  59. -s
  60. -- 
  61. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  62. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  63. FUCK the communications decency act.  Goddamned government.  [literally.]
  64. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  65.